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ABSTRACT 


This thesis details the PANSAT Command Language (PCL). The PCL is used for 
the efficient and reliable operation and commanding of PANSAT. This thesis describes each 
command of the PCL in detail and precisely defines the intended behavior and anticipated 
response a command will have on the various states of PANSAT. This thesis develops the 
user-syntax as well as the protocol-syntax for the PCL and begins to identify potential 
contingency scenarios. Numerous options and issues that were considered during the PCL 
development are provided and explanations given as to why certain options were chosen, 


while others were abandoned. 
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I. INTRODUCTION 


The Petite Amateur Navy Satellite (PANSAT) is a project sponsored and funded 
by the Navy Space Division, N-63 and administered by the Space Systems Academic 
Group (SSAG) of the Naval Postgraduate School (NPS). The military objectives of 
PANSAT are to enhance the education of military officers in the NPS Space Systems 
curricula and to demonstrate the feasibility of a quick-reaction, low cost communications 
satellite with digital, over-the-horizon communication, low probability-of-intercept and 
low probability-of-jamming characteristics. The educational objectives of PANSAT are 
to provide practical thesis research topics in space system engineering and operations, 
provide actual hardware and software design and integration experience, and in general, 
to give students exposure to development and life cycle issues associated with space 


systems. 


A. PANSAT MISSION DESCRIPTION 


PANSAT will be a low-earth orbiting, free-tumbling satellite providing digital, 
store-and-forward communication using primarily spread spectrum modulation. Binary 
phase shift keying (BPSK) modulation is also available and may be selected by the 
ground station 1n lieu of spread spectrum modulation. The satellite structure is 
constructed of aluminum in a polyhedral configuration with a diameter of about 19 inches 
(Fig. 1). PANSAT may be launched from a Shuttle Get Away Special (GAS) canister, 
which provides a typical orbit of 330 km at 28.5° degree inclination. An average of six 
minutes of communication per pass is possible with this orbit, providing communication 
possibilities throughout the day. [Ref. 1] 

General users on earth will be able to connect with PANSAT to send and receive 
electronic mail that is stored on-board, upload and download files, and read spacecraft 


telemetry. Multiple users will have the capability of communicating with PANSAT 
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Fig. 1 PANSAT Exploded View 








during the same window of time over one physical communication channel by using 
packet radio and the AX.25 protocol. [Ref. 1] 

The NPS ground station will act as the Spacecraft Operations Control Center 
(SOCC) and will be used to perform satellite commanding, telemetry collection and 


software updates. [Ref. 1] 


B. PANSAT COMMAND LANGUAGE 


The PANSAT Command Language (PCL) is used by the ground station to 
communicate or drive the Digital Control Subsystem (DCS) on board PANSAT. The 
DCS is PANSAT's command and data handling system. The DCS performs two major 
functions. It receives, validates, decodes and distributes commands to other spacecraft 
systems as well as gathers, processes and formats housekeeping and mission data for 
downlink, or use by an on-board processor. The DCS also performs additional functions, 
such as security interfaces, spacecraft time keeping, and computer health monitoring 
(watchdog). Hence, for the successful operation of PANSAT, an efficient and reliable 
means of communications with the DCS must be provided. The PCL is the 
vehicle/tool/method that provides such communications. [Ref. 2] 

One requirement of the PCL is reliability. To date (Sept. 95), according to Space 
Systems Academic Group documents, the total projected life cycle cost of PANSAT is in 
excess of $2 million dollars; hence, to have a catastrophic failure of the satellite because 
the commanding was unreliable, is unacceptable. In fact, any human induced 
catastrophic event would probably be considered unacceptable, except arguably for its 
educational benefit, which is one of PANSAT's primary missions. 

In addition, based on the currently projected orbital parameters (51° inclination, 
eccentricity = 0, period = 92 min.) the best case revisit scenario calculations show that 


PANSAT will be in view of the NPS ground station for an average of 6 minutes once, 





possibly twice per day [Ref. 3]. With this limited time-in-view, communications become 
vital and are thus directly related to the efficiency and reliability of the PCL. 

A number of ideas have been considered and implemented to ensure the reliability 
and efficiency of the PCL. These include: command acknowledgement, command 
verification, command encoding, single command per packet, verbose user syntax, super 


user commands, mission critical commands, and ground simulation. 








II. PANSAT HARDWARE ARCHITECTURE 


The PANSAT hardware architecture is comprised of the electrical power 
subsystem (EPS), digital control subsystem (DCS) and the communications subsystem 
(Fig. 2). Incoming signals are received by the antenna and passed to the RF section. The 
RF section downconverts the signal from the UHF 436.5 MHz frequency to the 70 MHz 
intermediate frequency (IF). From the RF section the signal is passed to the DCS where 


they are further processed and made ready for use by other subsystems on board the 


satellite (Fig. 3). 
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Fig. 2 PANSAT Hardware Architecture 
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Fig. 3 Information Flow Diagram 


A. RF SUBSYSTEM 


The basic components of the RF subsystem are two low noise amplifiers (LNA), 
two high pass amplifiers (HPA), two mixers, and nine switches of various types to 
control the system (Fig. 4). These components are combined to form dual transceivers. 

It is anticipated that ground controllers will take advantage of every opportunity 
to communicate with PANSAT, but this is not a requirement. Due to a number of 
circumstances, such as holidays or natural disasters, it may be several days between 
communications sessions. PANSAT will however, be expecting daily interaction with 
the NPS ground station. If PANSAT does not communicate with the NPS ground station 
for a few days (the exact number of days 1s still to be determined), software on board the 
satellite will attempt to reconfigure the state of the RF subsystem, the idea being that one 
or more components of the RF subsystem may have failed and ts thus preventing 
communications with the ground. The failure may or may not be in the RF subsystem, 


but if it is, cycling through the various switch settings and selecting different 
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Fig. 4 PANSAT RF Block Diagram 





combinations of components may solve the problem and allow communications to be 
reestablished. There are also high and low level PCL commands that may be issued to 
contro] the RF subsystem. So, in total there are three safety measures implemented to 
ensure reliability in the RF subsystem; the first being the fact that there are two 
transceivers, the second being that there will be software on board that will attempt to 
establish communication without ground intervention, and third being the PCL 


commands that can be used to exercise the system. 


B. DIGITAL CONTROL SUBSYSTEM (DCS) 


The received signal next flows to the DCS where it is further demodulated and 
converted to a digital signal that may be used by the other subsystems. The primary 
functions of the DCS are to control and operate the RF subsystem, control the EPS, 
gather and store telemetry data, perform memory management, and control the message 
handling. The DCS basically controls everything on the satellite. 

The DCS is fully redundant, consisting of two system control boards (SCA and 
SCB), two analog multiplexers (AMA and AMB), and two mass storage units (MSA and 
MSB) (Fig. 2). The analog multiplexers are used to collect temperature sensor data from 
throughout the spacecraft and send this data to the analog-to-digital (A/D) converters 
within the system controller. The mass storage units have a four megabyte capacity and 
are used for message and data storage. Ifa failure should occur on one of the DCS's 
paired components, such as MSA, a control board switching procedure is invoked to 
deactivate the failing components, in this case MSA and activate the redundant unit, in 
this case MSB. [Ref. 4] 

Each of the system control boards (SCA and SCB) of the DCS have the following 
main components: A microprocessor, serial communications controller (SCC), analog- 


to-digital converter (A/D converter), programmable peripheral interface (PPI), a PA-100 














spread spectrum demodulator board, error-detection-and-correction (EDAC) random 


access memory (RAM), and 32K of programmable read only memory (PROM) (Fig. 5). 
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Fig. 5 PANSAT System Controller [After Ref. 4] 


The microprocessor handles all of the software functions of the satellite. The 


SCC removes the data from the AX.25 protocol format and transfers digital information 


between the PA-100 and the microprocessor. The analog-to-digital converter interfaces 


directly with the microprocessor as an I/O addressed peripheral and accepts four separate 


analog inputs to provide one digital signal to the microprocessor. The PPI interface 


resides between the microprocessor and the peripheral control bus (PCB) and enables the 


system control boards to communicate with the other components connected to the PCB. 


9 








The MODEM board interfaces between the RF system and the SCC. It demodulates the 
incoming analog spread spectrum signal and converts it to a digital signal that may then 
be passed to and used by the microprocessor. The EDAC circuitry controls the SCB's 
RAM while the 32K PROM, which is connected directly to the microprocessors, contains 
the satellite initialization software. [Ref. 4] 

The analog multiplexers gather data from the 60 temperature sensors, multiplexes 
the data together, and sends this data via dedicated cables to the A/D converter and then 
onto the microprocessor to be used accordingly. Each system controller can control 
either of the two analog multiplexers. 

The two mass storage units connect to the microprocessor via the PPI and the 
PCB. Each unit has a four megabyte capacity and will provide storage for files, software, 
telemetry, and user mail. Each module also contains 512 kbits of flash memory. The 
flash memory will fly as an experimental, non-volatile memory device. 

As with the RF system, there are a number of high and low level PCL commands 
that may be used to control the DCS and its components. So, not only is there hardware 


back-ups, but also software back-ups. 


C. THE PCB AND THE PCL 


Although not considered a subsystem, the PCB is a critical component of the 
PANSAT hardware architecture. The PCB ts the device that connects together and 
allows the DCS to communicate and control the satellite subsystems. The PCB is a 
comparatively simple and robust piece of hardware and for this reason, there is no back- 
up or redundant counterpart. The PCB does, however, constitute a single-point-of-failure 
for the satellite. Not only is the physical integrity of the PCB important, but being able to 
control the PCB is equally important. 

At the most fundamental level the microprocessor ts controlling everything that is 


happening on board the satellite. The microprocessor accomplishes this by sending and 





a 


receiving information via input/output ports (I/O ports). Dedicated I/O ports are used to 
physically connect the components of the System Control Boards. By using what are 
referred to as I/O read and write instructions, the microprocessor may either read data 
from, or write data to other System Control Board components thus, ultimately 
controlling the satellite. At the lowest level, the PCL allows ground controllers to issue 
satellite commands using I/O statements. 

Above the microprocessor level, the PCB is controlling the satellite. Similar to 
I/O commands, ground controllers may use what are referred to as PCB read and write 
statements to control the PCB and again, ultimately the satellite. The distinction between 
I/O and PCB read and write statements is that from the user's perspective, PCB 
statements may be used to communicate directly between peripheral devices (via the 
PCB) without interaction with the microprocessor. 

In reality though, PCB commands are derived from a series of I/O statements. 
For example, there is a known and finite number of combinations in which the system 
controller communicates with peripheral devices and the I/O statements to do so are 
known. Instead of issuing perhaps a dozen I/O commands to accomplish a specific and 
routine task such as reading telemetry, a single PCB command is issued and interpreted 


by the microprocessor, which in turn issues the required I/O commands. 





D. ELECTRICAL POWER SUBSYSTEM (EPS) 


The primary function of the EPS is the collection, conversion, storage, and 
distribution of power to other subsystems tn the satellite. The EPS consists of 18 solar 
panels, which are mounted to the surface of the satellite, two redundant nickel-cadmium 
(NiCd) batteries (BATTA and BATTB), voltage, current, and temperature sensors, a 
watchdog timer, power regulation and conditioning circuitry, and a launch start-up switch 


(Fig. 6). The EPS performs battery charge regulation (trickle, reconditioning, charge), 
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Fig. 6 PANSAT EPS [From Ref. 4] 


multiplexes current and voltage readings, and gathers internal temperature data. Power is 
supplied by the EPS to other subsystems using dedicated circuitry on the PCB, and is 
controlled by the DCS. Current and voltage readings are collected in the EPS, 
multiplexed, and sent to the A/D converter located in the DCS. Temperature sensor lines 


from the EPS are sent to the temperature multiplexer modules. Readings from the DCS's 














A/D converters are sent to the microprocessor, where decisions are made regarding the 
regulation and control of the EPS. Based on these decisions, the DCS sends instructions 


back to the EPS via the PCB, and the desired EPS configuration is set (Fig. 7). [Ref. 4] 
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Fig. 7 EPS Signal Flow [After Ref. 4] 


The EPS has 18 solar panels and two batteries, and while not optimal, the satellite 
may continue to operate using a reduced number of panels or a single battery. The 
control and regulation circuitry autonomously maintains the EPS within operating limits, 
and high and low level PCL commands may be issued to control the system as well. The 
EPS control and power switching boards are not redundant however. Failure of one of 


these boards may lead to the loss of the satellite. 
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I. TELEMETRY 


PANSAT telemetry may be thought of in two broad categories; hardware 
telemetry and software telemetry. There are approximately 94 hardware telemetry points. 
These include temperature data for each of the 18 solar panels and voltage data for each 
of the ten cells of each battery. 

There are approximately 85 software telemetry points. Software telemetry 
provides ground controllers with statistics on the various events involving the satellite. 
These events include: number of logins and logouts, number of unauthorized login 
attempts, number of transmitted and received frames, and the number of errors in 
transmission. A complete listing of hardware and software telemetry points may be 
found in the PANSAT Software Detailed Design Document [Ref. 5]. 

Telemetry information enables ground controllers to evaluate PANSAT 
performance and gather health and status information. Additionally, telemetry data is 
continuously evaluated by the DCS to ensure that the other subsystems of the satellite are 
operating properly. If the DCS determines from the telemetry that a particular subsystem 
has malfunctioned or is approaching maximum or minimum operating conditions, the 
DCS will be able, to a limited extent, take autonomous corrective or preventative action 
to place the satellite in a safe state. 

Telemetry data is stored in two separate locations on-board the satellite. A 
complete set of telemetry is written to both the mass storage and the flash memory. The 
rate at which telemetry is gathered and stored may be adjusted using PCL commands. 
High, medium and low level PCL commands may be used to instruct PANSAT to 
downlink its telemetry data. At the lowest level, I/O or PCB read commands may be 
issued to recover telemetry. This is not the easiest or preferred method of recovering 
telemetry, but nonetheless, it is possible. At the mid-level, PCL commands may be 
issued to recover specific blocks of SRAM or flash memory. These mid-level PCL 


commands were not intended to be used to recover telemetry, but like the low-level I/O 
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and PCB commands, reading specific storage locations to recover telemetry is a viable 
option. At the highest level, there are PCL commands to be used specifically for the 
recovery of telemetry. Like all PCL commands, these high level telemetry recovery 
commands are in actuality low-level I/O and PCB commands that are grouped together to 
form macros. 

A final category of telemetry is known as recent telemetry. The DCS 1s 
continuously polling or gathering telemetry data. As mentioned above, the rate at which 
telemetry is collected and stored may be adjusted by issuing PCL commands. Recent 
telemetry is just that: the most recent value collected by a particular hardware sensor or 
software monitoring subroutine. Recent telemetry gives ground controllers the most up- 
to-date information on the status of PANSAT. How timely recent telemetry is, depends 
upon how often telemetry sensors gather information. If the telemetry polling rates are 
set at five minute intervals, ground controllers will know to an accuracy of five minutes 
the state of PANSAT. In practice, most telemetry data will be gathered on the order of 
seconds vice minutes and it should be kept in mind that the rate at which telemetry is 


gathered may be adjusted for each of the individual telemetry sensors. 
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IV. GROUND STATION HARDWARE AND SOFTWARE 
ARCHITECTURE 


The necessary components for the PANSAT ground station have been acquired 
and/or are being assembled by the Space Systems Academic Group and are located in 
Bullard Hall on the campus of the Naval Postgraduate School. The ground station will be 
used to perform a variety of tasks including commanding the satellite subsystems, 
uploading new software, and maintaining the store and forward messaging system. The 
ground station may be thought of as four distinct subsystems consisting of the 


transceiver, computer, antenna, and software. 


A. TRANSCEIVER SUBSYSTEM 


The transceiver subsystem consists of a transceiver, terminal node controller 
(TNC) anda MODEM. The transceiver is an ICOM 970H multi-band all mode 
transceiver, capable of operating on the two meter amateur band (144-148 MHz) and the 
70 centimeter amateur band (430-450 MHz). The radio can be controlled manually or by 
a computer (see Computer Subsystem description below). [Ref. 6] 

The TNC is an Advanced Electronics Applications (AEA) Inc., model DSP-2232 
multi-mode data controller. It interfaces between the computer and the transceiver and 
converts binary data from the computer to Frequency Shift Keying (FSK) modulated data 
for use by the radio, and vice versa. The DSP-2232 utilizes digital signal processing 
technology and is easily upgradable. [Ref. 6] 

The MODEM used in the transmitter subsystem is specific to PANSAT. Existing 
amateur radio satellites such as WO-18, DO-17, and AO-13 utilize a variety of 
modulation schemes such as 1200 bps AFSK packet, 1200 bps AFSK ASCII, and CW to 
name a few. MODEMs for these modulation types are available to amateur radio 
operators from a number of vendors. PANSAT employs 9842 bps direct sequence spread 


spectrum modulation. There is currently no commercially manufactured MODEM 
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suitable for PANSAT. Therefore, members of the SSAG are designing and building such 
a MODEM. The specifications and design for this 9842 bps direct sequence spread 
spectrum MODEM will be made available to amateur radio operators, who may then 


build the MODEM themselves. 
B. COMPUTER SUBSYSTEM 


The computer subsystem consists of a 486DX 33 MHz computer and an installed 
interface card called a Kansas City Tracker/Tuner (KCT). The KCT enables the 
computer, antenna rotor controller, and transceiver to communicate with each other. 
Utilizing satellite tracking software called Windows Satellite Programs (WiSP: see 
software subsystem below), the computer can point the antenna and tune the transceiver. 


This allows antenna pointing and radio tuning to be fully automated. [Ref. 6] 
C. ANTENNA SUBSYSTEM 


The antenna subsystem consists of an antenna, a rotor, and a preamplifier. The 
antenna is a crossed yagi design and is manufactured by Cushcraft Corp. (model AOP-1). 
The crossed yagi design allows the antenna to transmit and receive circularly polarized 
signals from spin stabilized satellites. [Ref. 6] 

The rotor is built by Yeasu Co. Ltd. (model G-5400B) and is actually a pair of 
rotors: One controlling the antenna azimuth (0-360 degrees) and the other controlling 
elevation (0-90 degrees). The KCT interfaces with the rotor controller and allows for 
computer control of the antenna system. [Ref. 6] 

The preamplifier is manufactured by ICOM Inc. (model AG-45). It is mast 
mounted near the antenna and used to amplify weak signals received from the satellite 


and send them to the transceiver. [Ref. 6] 
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D. SOFTWARE 


The PANSAT ground station will utilize three pieces of software, WiSP, the 
Graphical User Interface, and the PCL. The software that will control the antenna 
pointing and tracking is called WiSP and was written by Chris Jackson, ZL2ZTPO. WiSP 
is available from the American Satellite Corp. (AMSAT) and is widely used throughout 
the amateur radio community for PACKET satellite communications. WiSP is a 
compilation of seven separate programs designed to enable amateur radio operators to 
perform all the necessary functions to successfully communicate with PACSATs. These 
functions include among other things, antenna pointing and tracking, mail processing, 
and message creation and viewing. 

WiSP was designed for users and not operators of amateur radio satellites. 
Therefore, a Graphical User Interface, which is tailored specifically for use with 
PANSAT, is being developed by Jens Bartschat, a German Naval Officer participating in 
the Department of the Navy's Personnel Exchange Program (PEP). WiSP will be run 
minimized in the windows environment and used only for antenna pointing and tracking 
and AX.25 protocol functions. 

A Graphical User Interface specifically for PANSAT will be needed to interact 
with the spacecraft. Utilizing this interface, ground controllers will be able to access the 
PCL to compile and transmit command scripts. The Graphical User Interface will also be 


used to display telemetry data and to perform any required housekeeping functions. 
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V. OPERATIONAL SCENARIO 


Communication with satellites is typically thought of as occurring in three distinct 
phases consisting of pre-pass, pass, and post-pass events. This three phase methodology 
is particularly useful when communicating with low earth orbiting satellites such as 


PANSAT because it ensures maximum data throughput during the limited time in view. 


A. PRE-PASS 


In many respects, the pre-pass phase of a communications session is the most 
critical. The amount and quality of preparation for a pending pass will directly affect the 
success of the pass and post-pass events and ultimately the satellite operation. During the 
pre-pass phase, ground controllers should verify the status of the ground station. This 
consists of ensuring that all of the equipment from the antenna to the transceiver is 
functioning properly, and if it is discovered that a piece of equipment has for some reason 
become inoperable, it should be repaired or replaced prior to the pass. 

Ground controllers should review the operations log and the planned activities to 
familiarize themselves with the anticipated state of PANSAT and to be appropriately 
prepared for the upcoming pass. Ground station displays should also be activated and 
made ready for the pass. 

The most important part of the pre-pass event is the construction of any command 
scripts that are to be transmitted during the pass. A command script consists of one or 
more individual commands selected from the PCL, that are grouped together and 
transmitted so as to command PANSAT into the desired state. Say for example that it has 
been determined that based on the telemetry from the previous pass that the mass storage 
was full and the system clock was inaccurate. To rectify the situation, a ground controller 
could choose the appropriate commands from the PCL and compile a script to perform 
the necessary tasks automatically once the communications link is established and 


without any additional interaction. 
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Scripting is a very powerful methodology and maximizes data throughput. 
Ground controllers are not sitting at a terminal issuing PCL commands manually, one by 
one, wasting critical time-in-view. Scripting also increases reliability because scripts 
may be compiled and simulated prior to a pass to ensure they have the desired effect on 


the satellite. 


B. PASS 


The FCC prohibits satellite links being established less than 10 degrees above the 
horizon [Ref. 3]. Therefore, the pass phase begins when the satellite moves 10 degrees 
above the horizon and 1s in view of the ground station. WiSP is continuously calculating 
pointing and tracking data and sending this information to the computer subsystem, 
which in turn is commanding the antenna and transceiver subsystems in an attempt to 
establish the communications link. 

Once the communications link is established, PANSAT will immediately be 
commanded to transmit its current telemetry data. Once this telemetry data is received, it 
will automatically be evaluated to see if the spacecraft is operating nominally. Ground 
controllers will have assembled command scripts based on nominal operating conditions 
and if this is not the case, the scripts that they have assembled may be inappropriate. 

Once the state of PANSAT has been verified normal communication may begin. 
PANSAT will be commanded to complete downlinking any partially transmitted data or 
files from the previous pass such as events logs, telemetry, or command 
acknowledgements, and then begin sending new data. Ground controllers will also be 


able to uplink files, software, and perform housekeeping functions. 
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C. POST-PASS 


When PANSAT moves over the horizon and out of view of the ground station, the 
pass is over and the post-pass phase begins. At this point, everything that occurred 
during the pass should be logged in one way or another, either manually or automatically 
by the ground station computer. 

The operations log, which will probably be hand written initially and entered into 
a data base later, should indicate at a minimum the time and date that the pass started and 
stopped, the primary ground controller's name and if the planned activities for the pass 
were accomplished. These actions may include checks to verify that anticipated data 
such as event logs and command acknowledgements were received. Also, any mail or 
files addressed to the ground station should be evaluated and distributed accordingly and 
software and hardware problems should be annotated. 

It is envisioned that much of the record keeping, archiving, and report generating 
will be automated using the graphical user interface and that the requirement for hand 
written paper logs will be a minimum. All data that is transmitted to and received from 
PANSAT will pass through the graphical user interface, thus making the task of record 
keeping a straight forward process. For example, when the current telemetry data is 
received from PANSAT it will be interpreted and displayed by the graphical user 
interface. At the same time, transparent to the ground controller, this incoming telemetry 
will be archived and a record made that the telemetry was received. The same principle 
applies when uplinking to PANSAT. Any information which passes through the 
graphical user interface, which is essentially everything, is written to a file, thus greatly 
simplifying the task of record keeping, archiving and report generation. 

Stored telemetry and ground controller logs will be used to identify any spacecraft 
anomalies or out-of-bound situations. Ideally, enough information will be available in 


the telemetry to determine the cause of such anomalies 
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VI. PCL: THE DETAILS 


To this point, the relevance of the satellite subsystems, PCB, telemetry, ground 
station, and operations as they relate to the PCL have been shown. To briefly summarize, 
the PCL may be used at the lowest level to control the microprocessor via I/O statements. 
At a higher level, the PCL may be used to control the subsystems via PCB statements. At 
a higher level still, the PCL may be used to control systems directly such as toggling 
between transceivers or mass storage units. Finally in the hierarchy of control, the PCL 
may be used for high-level control, such as retrieving telemetry. In this high-level control 
scenario, the PCL is not only controlling the mass storage unit directly, but instructing the 
mass storage to perform a specific task, namely, to determine where in the mass storage 
the telemetry is located, go there, retrieve the data and place this data on the PCB where it 
will be made ready by the other subsystems for transmission. The PCL is also an integral 
part of spacecraft operations and is a major consideration in the design and performance 
of the ground station. What follows, is a compilation of issues, thoughts, and ideas 


concerning the DCS of PANSAT. What follows are the details of the of the PCL. 


A. COMMAND ACKNOWLEDGEMENT 


Command acknowledgement is a technique used to increase the PCL efficiency. 
In order to maximize communications during a given pass, PANSAT will not 
acknowledge every command from the PCL (and hence the ground station). Instead, 
only specific commands will be acknowledged (see Appendix A) and it should be 
assumed, that if a command was issued, it was executed. PANSAT will maintain an 
event log that will log all of the commands that it has executed. Therefore, if there is 
doubt as to whether or not a specific command was executed, say from out of limits 
telemetry data or an unexpected satellite state, the event log may be downlinked by 


ground controllers and analyzed for the appropriate indications. By assuming that issued 
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commands were executed properly, valuable time is not wasted informing ground 
controllers at the beginning of every communication session of the commands that have 
been executed since the last contact with PANSAT and thus, the available time-in-view 
of the satellite has been maximized. 

PCL commands that will be acknowledged are those commands that require 
PANSAT to respond with some sort of data. For example, when ground controllers 
command PANSAT to downlink its current telemetry data, receipt of that data should 
serve as the acknowledgement that the command was executed properly. This technique 
increases efficiency by not requiring separate dedicated responses for both command 
acknowledgement and transmitted data. Instead, the received data is the 


acknowledgement. 


B. COMMAND VERIFICATION 


Command verification differs from command acknowledgement in that command 
verification requires a response from the ground controller, while command 
acknowledgement involves a response from PANSAT. Also, command verification is an 
attempt to increase reliability, while as stated above, command acknowledgement is an 
attempt to increase efficiency. 

Command verification is invoked automatically by the ground station software 
any time a ground controller attempts to issue a mission critical command, (see Appendix 
A). When a mission critical command is issued or a command script is built containing a 
mission critical command, the ground station software will recognize this and query the 
intentions of the operator. This gives the ground controller the opportunity to reflect for a 
moment on what their intentions really are. Was this simply a typo in the command 
script and was not really their intention at all, or after thinking about it, should they 
consult somebody before issuing this command? In any event, command verification is 


simply intended to provide another level of reliability to the PCL. 
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One attribute of command verification is, that like command acknowledgement, it 
is adjustable. That is, the PCL commands that trigger the command verification 
subroutine on the ground station software may be changed as the experience level of 
operators increases. Initially it is envisioned that command verification will be used only 
In conjunction with mission critical commands. Eventually ground controllers may be 
given a rating based on experience. Each rating will require a subset of commands to 
pass through the command verification algorithm. This gives new operators the 
opportunity to gain familiarity with the PCL while minimizing the probability that they 
are allowed to make a mission critical error. At the same time however, users that are 
very familiar with the PCL will not be constantly queried. And finally, while not 
recommended, it is even possible to disable command verification entirely. 

Another scenario may be that after gaining operational experience with PANSAT 
it is determined that certain commands require an inordinate amount of time to execute 
during a given pass. Under these circumstances, it may be desirable to filter these 
commands through the command verification subroutine. For example, if an operator 
desires to downlink two days worth of telemetry and uplink a command script containing 
20 instructions, this is a relatively large amount of data and there may not be enough 
time to accomplish this task. Command verification could be used in this scenario to 
notify the ground controller that the time-in-view is limited during this particular pass and 
it is recommended that the telemetry request be reconsidered in order to ensure the 20 


instruction command script is transmitted. 
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C. DATA INTEGRITY 


A very powerful and easily implemented method of ensuring the reliability of the 
PCL 1s the use of the AX.25 protocol itself. The AX.25 protocol incorporates a technique 
known as a cyclic redundancy check (CRC-16) and can be explained as follows. Given a 
k-bit message, the transmitter generates an n-bit sequence, known as a cyclic redundancy 
check (CRC), so that the resulting frame, consisting of k+n bits, is exactly divisible by 
some predetermined number. The receiver then divides the incoming frame by the same 
number and, if there is no remainder, assumes that there was no error [Ref. 7]. It can be 
shown [Ref. 7, 8], with some qualification, that CRC-16 is capable of detecting all single- 
bit errors, all double-bit errors, and any odd number of errors. CRC-16 is a specific type 
of CRC and differs from CRC-12 or CRC-32 in that it 1s popular for 8 bit characters and 
results in a 16 bit CRC. 

Command encoding is an attempt to increase both reliability and efficiency. 
Command encoding can be accomplished using any number of bits, so long as there are 
enough bits to provide for the number of commands needed. For example, if the PCL 
contained 25 commands (vice the actual number of approximately 50), at least five bits 
would be required (2° = 32) for the command encoding because any number of bits less 
than five (ie., 4 bits, or 2* = 16) would not provide enough unique bit patterns to encode 
all 25 of the commands. 

Specifically, eight bit command encoding was chosen because it provides the 
required number of unique bit patterns for the PCL, is efficient and works well with 
CRC-16 as discussed above. If 16 bits had been chosen instead of eight, the eight most 
significant bits of each pattern would not be required for uniqueness, but would still be 
transmitted, thus effectively slowing the data rate and leading to inefficiency. In 
addition, eight bit encoding is widely used for programming and leads to simplicity in 
terms of the actual coding of the communication software. Lastly, eight bit encoding 


makes possible another layer of reliability. 
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With eight bit encoding (or n bit encoding in general), it is conceivable that a 
packet may experience a burst error during transmission that is not detected by the CRC- 
16, resulting in a single bit being "flipped." If 11111111 is transmitted from the ground 
station and 11111110 is received, PANSAT may interpret this as a valid command and 
execute the command accordingly. However, this was not the intention of the ground 
station and depending on the nature of the command, could be potentially catastrophic. 
One technique for solving this bit flip problem is to formulate the bit patterns of the 
individual commands so that the flipping of any single bit will result in an invalid bit 
pattern. So now, when 11111111 is transmitted from the ground station and 11111110 is 
received, this is an invalid command and PANSAT disregards it. Eight bit encoding 


provides enough bit patterns to implement this technique. 


D. MULTIPLE COMMANDS PER DATA PACKET 


The transmission of multiple commands per data packet has an effect on both 
reliability and efficiency. If several commands are grouped together and transmitted in a 
single data packet, the probability of the packet being corrupted during transmission is 
increased. Simply put, the more data there is to corrupt, the greater the probability that 
the data will be corrupted. 

So, trade-offs need to be made. If only one command is transmitted per AX.25 
information field (see Fig. 8 for a description of the AX.25 information frame), PCL 
reliability is increased by minimizing the probability that a packet is corrupted, because 
there is a minimum of data to corrupt and the communications software is less complex. 
At the same time however, efficiency decreases because most of the transmitted 
information is overhead, not informational data. 

Conversely, if an attempt is made to increase efficiency by sending multiple 
commands per data packet, reliability is reduced because the larger packet has a greater 


probability of being corrupted and the communications software is more complex. 
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Efficiency is decreased because more time is now being spent retransmitting corrupted 


frames rather than transmitting new frames. 





Flag Address Control PID Info Field CRC Flag 
O1NI1110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits OLl11110 


Fig. 8 AX.25 Information Frame 





Assuming the maximum information frame size of 332 bytes (2656 bits) and a bit 
error rate (BER) of 1x10° bits/error, that means that there will be 0.0027 errors/frame, or 
] error in approximately every 370 frames with approximately 23% of the transmitted 
data as overhead information. 

For comparison, now assume that only one command, that is 10 bytes in length, is 
transmitted in the AX.25 information field and that the frame size is now 86 bytes (688 
bits) instead of 332 bytes. Using the same BER, there is now expected to be 1 error in 
approximately every 1454 frames, but 88% of the data is now overhead. 

Another consideration is how PANSAT will process multiple commands per data 
packet. For instance, will PANSAT read the entire information field of the AX.25 frame 
and execute the commands within that field based on some sort of priority scheme, or 
will commands be executed as they are received, in a First In First Out (FIFO) fashion, 
regardless of their relative importance or, should each command be uplinked one at a 
time in its own command message? If PANSAT executes instructions as they are 
received, this increases the complexity of the dialog between the ground station and 
PANSAT. For example, if the spacecraft is processing a telemetry request command 
while uplink commands are still being sent, the possibility of packet collision increases. 

Prioritization of PCL commands in uploaded scripts will be performed by the 
ground station software. Command scripts which require multiple downlinks such as 


telemetry or event logs, or time-sensitive processing will be divided on the ground into 
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separate command messages. These messages will be uplinked one at a time allowing 
time for the downlink or command execution. By doing this, the probability of 


transmission collisions, of downlinked telemetry and uplinked commands, is avoided. 


E. SUPER USER/MISSION CRITICAL COMMANDS 


In order to increase reliability by restricting user access, certain commands of the 
PCL have been designated as superuser commands. Superuser commands are those 
commands that affect the configuration of the satellite (see Appendix A for a listing and 
description of Super User commands) and will require a valid password prior to 
transmission. 

Mission Critical commands have also been designated (see Appendix A for a 
listing and description of Mission Critical commands) . Mission Critical commands are a 
subset of Super User commands and as such, also require a valid password prior to 
transmission. Like Super User commands, Mission Critical commands may also affect 
the state of PANSAT, but can do so irreversibly and catastrophically, so care should be 


taken when issuing Mission Critical commands. 


F. PASSWORDS 


Passwords are an attempt to increase the reliability of the PCL. The majority of 
commercial and military satellites utilize sophisticated encryption algorithms to encrypt 
their telemetry data. Encryption offers security and hence reliability by ensuring that 
only authorized users are allowed to interact with the satellite. 

PANSAT has no need for sophisticated encryption. Its primary mission is as a 
teaching and learning aid for the Space Systems Academic Group and not as a secure 
satellite communications system. Additionally, PANSAT will be made available to 


amateur radio operators around the globe and encrypting telemetry would be senseless. 
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There are however commands in the PCL that if issued improperly or maliciously, 
could cause catastrophic failure to PANSAT. It has been decided for this reason, that 
there should be some simplified or elementary security measure implemented. One 
security option considered 1s the use of passwords. Prior to the launch of PANSAT, a 
password table will be generated and a copy placed in the satellite's static ROM as well as 
on the NPS ground station computer. An individual password will consist of 7 randomly 
generated alpha numeric ASCII characters and there will be approximately 1600 unique 
passwords in the table (enough for the expected 2-3 year mission duration). Under 
«,ormal circumstances, passwords will change once per day. 

When the NPS ground station establishes communications with PANSAT, 
PANSAT will automatically transmit its current on-board clock information, that is, the 
time that PANSAT thinks it is. For a variety of reasons, this date and time information 
may or may not be accurate. Regardless of the accuracy, the ground station software will 
take this information, enter into the password table and retrieve the proper password for 
that particular date and time. Henceforth, a correct password will be appended 
automatically to any commands requiring one (see appendix A for a list of commands 
that require a password) without any interaction with the ground controller. This 
automated password look-up method provides an additional layer of security in that 
passwords will not be readily available and mistakes from manual look-ups will be 
eliminated. A hard copy printout of the password table will be kept locked in the SSAG 
safe in Bullard 125. 

It is anticipated however, that for a variety of reasons, PANSAT will be resetting 
its systems and hence its on-board clock at frequent intervals. This means that when 
PANSAT transmits its date/time information at the beginning of a communications 
session, the password look-up subroutine will locate a password that has already been 
used, possibly dozens of times. Although unlikely, it is conceivable that a particularly 
motivated individual conducting TT&C analysis/surveillance may detect the fact that the 
same passwords are being used over and over, and use this observation to the detriment of 


the satellite. Therefore, the first three days of passwords (which is the longest anticipated 
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time that NPS will not communicate with PANSAT) will change every 30 minutes vice 
once per day. Hopefully, any ongoing surveillance effort will essentially be negated by 


changing passwords so frequently that packet recovery becomes impossible. 


G. VERBOSE USER SYNTAX 


Verbose user syntax is an attempt to increase the efficiency and reliability of the 
PCL. Individual commands of the PCL could have been constructed with a variety of 
different syntaxes. For example, the syntax for the command to charge battery B could 
have looked like: charge_battery_b, or chargebatteryb, or ch_batt_b, or etc. Command 
syntax should be verbose enough to be easily understood and recognizable, but at the 
same time concise. When issuing commands or building a command script, a ground 
controller will essentially be using a text editor. Easily understood and recognizable 
commands increases the reliability of the PCL by reducing confusion and mistakes. At 
the same time, the concise nature of the commands eliminates unnecessary keystrokes 
and makes command editing more efficient. 

It should be kept in mind that the actual length or number of characters associated 
with an individual command is only a consideration for editing and not in data 
throughput. When individual commands or command scripts are written with the ground 
station command editor, these ASCII character representations of the commands (or 
scripts) are converted, along with any required parameters, to a one byte command 
number and then to hexadecimal format prior to transmission. Therefore, even though an 
individual command may be 20 characters long, this does not mean that 20 bytes need be 
transmitted to issue the command. Instead, the 20 character long command will be 


converted to an equivalent one byte hexadecimal! value and then transmitted. 
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H. GROUND SIMULATION 


Ground simulation is an attempt to increase efficiency and reliability. Based on 
the commands issued and telemetry received from the previous contact, ground 
controllers will be able to estimate (albeit not precisely) the state of PANSAT on the next 
pass. Utilizing these estimates, commands and command scripts may be prepared ahead 
of time, simulated on the ground, and made ready for transmission the moment 
communications are established with PANSAT. Ground simulation incre«ses reliability 
by ensuring that the commands to be issued have their intended response. Efficiency is 
increased by not utilizing the limited time-in-view sending commands which are 


determined inappropriate through ground-based simulation. 
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VII. CONCLUSIONS AND FOLLOW ON WORK 


This thesis documents the thoughts and ideas various people of the Space Systems 
Academic Group have had on PANSAT command and data handling and results in the 
first iteration of the PCL. The PCL incorporates a number of techniques that increase 
efficiency and reliability and is therefore very robust and ideal for the military and 
educational missions of the satellite. 

As the launch of PANSAT draws closer, additional iterations need to be 
performed on the PCL in order to further refine reliability and efficiency. Already, 
additional required commands and opportunities to combine existing commands have 
been identified. Also, there are still a number of PANSAT response data formats such as 
telemetry data, that are undefined and need to be determined. Finally, and it has already 
begun, the PCL needs to be translated from this document and made into compiled usable 
software, which in turn will need to go through several iterations for a final reliable 


product. 
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APPENDIX A. PANSAT COMMAND LANGUAGE (PCL) 


Appendix A, which is intended to be used as a reference source by ground 
controllers and software designers, is a detailed description of the PCL, and specifies 
among other things user syntax, command descriptions and expected responses to 


commands. The Appendix is arranged in alphabetical order by command name. 
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TIME-TAGGED COMMANDING 


Operation: Add a command from the PANSAT command buffer 
Command: add_cmd <Command> <Time> 
Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
OFL11110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1111110 


AX.25 Information Frame 


Command (1 Byte) Password Command (1 Byte) Parameters (1 Byte) UTC (4 Bytes) 
add cmd (4 Bytes) <Command> <Parameters> <Time> 


AX.25 Information Field 





Required Parameters: <Command> (A valid PANSAT command) 


<Time> (dd/mm/yy/hh/mm/ss) 
Optional Parameters: None 
Function: add_cmd <Command> <Time> is used to add a command to 


the PANSAT command buffer. The required parameters are 
the <Command> to add to the buffer and the <Time> that the 
command should be executed. Upon receipt, PANSAT will 
verify that the <Time> parameter is valid and will ensure that 


no two commands have the exact same time of execution. If 
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Super User: 


Expected Response: 





PANSAT determines that two commands have the same time 
of execution, the commands will be prioritized on the basis of 
which command was sent to the buffer first. The first 
command to the buffer will be executed first (FIFO). The 
number of commands allowed in the command buffer is only 


limited by the size of the buffer. 


Yes 


PANSAT will not directly confirm or verify the command 
add_cmd <Command> <Time> and unless there are 
indications to the contrary, it should be assumed that the 
command was executed properly. If there is doubt whether or 
not the command was added to the command buffer or that the 
command was executed at the specified time, the ground 
controllers should analyze the event log for the appropriate 


indications. 
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TASK CONTROL 


Operation: Upload a software task to PANSAT 
Command: add_task <Task Name> 
Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
O1111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits 01111110 


AX.25 Information Frame 





Command (1 Byte) Password Task Name Task Length File Data ... 
add_task (4 Bytes) <Task Name> (2 Bytes) (x Bytes) 


AX.25 Information Field 





Required Parameters: <Task Name> The name of the task to be uploaded and may 
be up to eight characters in length. All software tasks have the 
same three character extension. All software tasks to be added 
or uploaded will be located in a separate default software task 
subdirectory on the ground station hard drive and therefore a 
path need not be specified when issuing this command. The 
default software task subdirectory may however be overridden 


and specified by the ground controller if the need arises. 


Optional Parameters: None 
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Function: 


Super User: 


Expected Response: 


add_task <Task Name> is used to upload software tasks to 
PANSAT. Software tasks are executable programs that are 
written and compiled on the ground and instruct PANSAT how 


to perform under various circumstances. 


Yes 


PANSAT will not directly confirm or verify the command 
add_task <Task Name> and unless there are indications to the 
contrary, it should be assumed that the command was executed 
properly. If there is doubt whether or not the task was added to 
the task queue, ground controllers should execute a list_ task 
command to verify the contents of the task queue and the status 
of each task (PANSAT is limited to a maximum of 30 tasks). 
Ground controllers may also examine the event log in order to 


confirm that the command was executed. 
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OS CONTROL 


Operation: Perform a ROM boot on currently selected DCS 
Command: boot_rom 


Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
O1111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits OIINIITIO 


AX.25 Information Frame 





Command (1 Byte) Password 
boot_rom (4 Bytes) 


AX.25 Information Field 
Required parameters: None 
Optional Parameters: None 
Function: boot_rom is used to reset or "warm boot" the software on the 


current system controller. This forces a complete execution of 
all of the initialization code, including the battery charge 
monitor and wait for NPS contact followed by the software 
uploads from NPS. boot_rom only initializes hardware, it 


does not power cycle the hardware. 
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Super User: Yes 


Expected Response: Assuming no battery charging is necessary, PANSAT will be 
listening for NPS to begin software uploads. If charging is 
required, PANSAT will complete battery charging then 


proceed to listen for the NPS ground station. 
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BATTERY CONTROL 


Operation: Charge Battery A 
Command: charge_batt_a 
Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
01111110 112/560 Bits 8 Bits | 8 Bits 256 Bytes 16 Bits OTTTITIO 


AX.25 Information Frame 





Command (1 Byte) Password 
charge batt_a (4 Bytes) 


AX.25 Information Field 
Required Parameters: None 
Optional Parameters: None 
Function: charge_batt_a commands PANSAT to charge battery A. 
Super User: Yes 
Expected Response: PANSAT will not directly confirm or verify the command 


charge_batt_a and unless there are indications to the contrary, 
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it should be assumed that the command was executed properly. 
If there is doubt whether or not the command was executed, the 
ground controllers should analyze the event log and telemetry 


data for the appropriate indications. 
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BATTERY CONTROL 


Operation: Charge Battery B 
Command: charge_batt_b 
Protocol Syntax: 


Fiag Address Control PID Info Field CRC Flag 
O1111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1111110 


AX.25 Information Frame 





Command (1 Byte) Password 
charge_batt_b (4 Bytes) 


AX.25 Information Field 
Required Parameters: None 
Optional Parameters: None 
Function: charge_batt_b commands PANSAT to charge battery B. 
Super User: Yes 
Expected Response: PANSAT will not directly confirm or verify the command 


charge_batt_b and unless there are indications to the contrary, 
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it should be assumed that the command was executed properly. 
If there is doubt whether or not the command was executed, the 
ground controllers should analyze the event log and telemetry 


data for the appropriate indications. 


47 











TIME-TAGGED COMMANDING 


Operation: Delete a command from the PANSAT command buffer 
Command: delete_cmd <Command> <Time> 
Protocol Syntax: 


| Flag Address Control PID Info Frame CRC 
O1I11110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits 


AX.25 Information Frame 





Flag 
01111110 





Command (1 Byte) Password Command (1 Byte) UTC (4 Bytes) 
delete_cmd (4 Bytes) <Command> <Time> 


AX.25 Information Field 


Required Parameters: <Command> (A valid PANSAT command) 


<Time> (dd/mm/yy/hh/mm/ss) 
Optional Parameters: None 
Function: delete_ cmd <Command> <Time> is used to delete a 


command from the PANSAT command buffer. The required 
parameters are the <Command> to delete from the buffer and 


the <Time> that the command was to have been executed. 
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Super User: 


Expected Response: 





These two parameters will be compared to the contents of the 


command buffer and the appropriate entry will be deleted. 


Yes 


PANSAT will not directly confirm or verify the command 
delete_cmd <Command> <Time> and unless there are 
indications to the contrary, it should be assumed that the 
command was executed properly. If there is doubt whether or 
not a particular command was deleted from the command 
buffer, the ground controllers should analyze the event log for 


the appropriate indications. 
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FILE SYSTEM CONTROL 


Operation: Delete a file from PANSAT 
Command: delete_file <Filename> 
Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
OlL1IttO 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1LIITIO 


AX.25 Information Frame 


Command (1 Byte) Password DOS File Name 
delete_file (4 Bytes) <Filename> 


AX.25 Information Field 


Required Parameters: <Filename> DOS filename format. May be up to eight 
characters in length followed by an optional three character 
extension and a null string. 


Optional Parameters: Use of wildcards is still to be determined. 


Function: The command delete_file <Filename> is used to delete 


specific files from the file directory. 


Super User: No 





Expected response: 


PANSAT will not directly confirm or verify the command 
delete_file <Filename> and unless there are indications to the 
contrary, it should be assumed that the command was executed 
properly. If there is doubt whether or not the command was 
executed, ground controllers should examine both the file 


directory and the event log for the appropriate indications. 
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TASK CONTROL 


Operation: Delete a software task from PANSAT 
Command: delete_task <Task Name> 


Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
O1111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits OLIITIIO 


AX.25 Information Frame 





Command (1 Byte) Password Task Name 
delete_task (4 Bytes) <Task Name> 


AX.25 Information Field 


Required Parameters: <Task Name> The name of the task to be deleted from the 
PANSAT task queue. May be up to eight characters in length. 


All software tasks will have the same three character extension. 
Optional Parameters: None 


Function: delete_task <Task Name> is used to delete a software task 
from the PANSAT task queue. Software tasks are executable 
programs that are written and complied on the ground and 


instruct PANSAT how to perform under various circumstances. 


D2 





Super User: 


Expected Response: 





NOTE: A SOFTWARE TASK MUST BE STOPPED 
BEFORE IT CAN BE DELETED. 


Although not mission critical, PANSAT will query the NPS 
ground station prior to the execution of the command 
delete_task <Task Name> in order to verify its intentions. 
The NPS ground station will be immediately notified that a 
software task has been deleted and an entry will be made to the 
event log. If PANSAT moves over the horizon without being 
able to notify the NPS ground station that a software task has 
been deleted, PANSAT will not attempt to inform the NPS 
ground station of this event on subsequent communication 
sessions. At this point, if there is doubt whether or not the task 
was deleted from the task queue, ground controllers should 
execute a list_tasks command to verify the contents of the task 
queue and the status of each task (PANSAT is limited to a 
maximum of 30 tasks). Ground controllers may also examine 
the event log in order to confirm that the command was 


executed. 
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FILE SYSTEM CONTROL 


Operation: Get the PANSAT file directory 


Command: directory 


Protocol Syntax: 





Flag Address Control PID Info Field CRC Flag | 
01111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1111110 


AX.25 Information Frame 





Command (1 Byte) 
directory 


AX.25 Information Field 


Required Parameters: None 

Optional Parameters: None 

Function: The command directory ts used to get a listing of the 
PANSAT file directory. 

Super User: No 
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Expected response: PANSAT will not directly confirm or verify the command 
directory. Receipt of the directory should serve as the 
indication that the command was executed properly. If there is 
doubt whether or not the command was executed, ground 
controllers should examine the event log for the appropriate 
indications. The protocol syntax for the response to the 


command directory is as follows: 





Flag Address Control PID Info Field CRC Flag 
O1IT1110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits 01111110 


AX.25 Information Frame 





Command (1 Byte) Directory Length (2 Bytes) Directory Contents ... 
directory <Length> (X Bytes) 


AX.25 Information Field 
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BATTERY CONTROL 


Operation: Discharge Battery A 
Command: discharge batt_a 


Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
O1111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1TE1110 


AX.25 Information Frame 


Command (1 Byte) Password 
discharge batt_a (4 Bytes) 


AX.25 Information Field 


Required Parameters: None 

Optional Parameters: None 

Function: discharge_batt_a commands PANSAT to discharge battery A. 
Super User: Yes 

Expected Response: PANSAT will not directly confirm or verify the command 


discharge_batt_a and unless there are indications to the 
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contrary, it should be assumed that the command was executed 
properly. If there is doubt whether or not the command was 
executed, the ground controllers should analyze the event log 


and telemetry data for the appropriate indications. 


4. 





BATTERY CONTROL 


Operation: Discharge Battery B 
Command: discharge batt _b 


Protocol Syntax: 


Flag Address Contro! PID Info Field CRC 
01111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits 


AX.25 Information Frame 





Flag 
O1t11110 





Command (1 Byte) Password 
discharge _batt_b (4 Bytes) 


AX.25 Information field 


Required Parameters: None 

Optional Parameters: None 

Function: discharge_batt_b commands PANSAT to discharge battery B. 
Super User: Yes 

Expected Response: PANSAT will not directly confirm or verify the command 


discharge_batt_b and unless there are indications to the 
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contrary, it should be assumed that the command was executed 
properly. If there is doubt whether or not the command was 
executed, the ground controllers should analyze the event log 


and telemetry data for the appropriate indications. 
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USER CONTROL 


Operation: Disconnect communications with all current users. 


Command: drop_users 
Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
O1111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits OLIIEIIO 


AX.25 Information Frame 





Command (1 Byte) Password 
drop_users (4 Bytes) 


AX.25 Information Field 


Required Parameters: § None 
Optional Parameters: None 
Function: drop_users commands PANSAT to discontinue 


communications will all current users except the NPS ground 
station. This command should be tssued whenever it is 
necessary for the NPS ground station to have exclusive access 
to PANSAT for such purposes as software uploading or 


troubleshooting. For most scenarios the drop_users command 


60 


Super User: 


Expected Response: 





will be used in conjunction with the lockout_users command 
to ensure that once all unauthorized users have been 


disconnected, no users will be allowed to log onto PANSAT. 


Yes 


PANSAT will not directly confirm or verify the command 
drop_users and unless there are indications to the contrary, it 
should be assumed that the command was executed properly. 
If there is doubt whether or not the command was executed, the 
ground controllers should analyze the event log for the 


appropriate indications. 
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FILE SYSTEM CONTROL 


Operation: Download a file from PANSAT 
Command: get file <Filename> 
Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
O1NETIIO 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1NIITEIO 


AX.25 Information Frame 





Command (1 Byte) File Name 
get file <Filename> 


AX.25 Information Field 


Required Parameters: <Filename> DOS filename format. May be up to eight 
characters in length followed by an optional three character 


extension and a null string. 


Optional Parameters: None 


Function: The command get_file <Filename> is used to get or download 


a specified file from PANSAT. 


Super User: No 
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Expected Response: PANSAT will not directly confirm or verify the command 
get_file <Filename>. Receipt of the specified file should serve 
as indication that the command was executed properly. If there 
is doubt whether or not the command was executed, ground 
controllers should examine the event log. The protocol syntax 
for the response to the command get_file <Filename> is as 


follows: 





Flag Address Control PID Info Field CRC Flag 
01111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits OTTI1110 


AX.25 Information Frame 





Command (1 Byte) File Name File Length File Data ... 
get file <filename> (4 Bytes) (XXX Bytes) 


AX.25 Information Field 
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DIRECT LOW-LEVEL OPERATIONS 


Operation: Perform I/O port read 
Command: io_read <Port> 


Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
OFII1T0 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits OLIITITO 


AX.25 Information Frame 


Command (1 Byte) Port (2 Bytes) 
io_read <Port> 


AX.25 Information Field 


Required Parameters: <Port> The CPU I/O port to be read. Hex range of allowable 
values is 0O-FFFF. A complete listing of I/O ports and their 
definitions can be found in the Appendix B. 


Optional Parameters: None 


Function: The io_read command 1s used to directly read the I/O ports of 
the microprocessor. These ports must be controlled in order to 


communicate with various PANSAT peripheral devices such as 
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the programmable peripheral interface (PPI) and serial 
communications controller (SCC). Under normal operating 
conditions, I/O statements are embedded within the PANSAT 
Command Language (PCL) and are thus transparent to the 
ground controllers. I/O statements can be quite complicated, 
even to perform the simplest of tasks and this method of 
embedding the I/O statements simplifies PANSAT 


commanding and reduces the probability of errors. 


Super User: No 


Expected Response: Care should be taken when issuing I/O read commands. 
PANSAT will not directly confirm or verify individual I/O read 
commands. Receipt of the requested information should serve 
as the indication that the command was executed properly. 
Since it is difficult to anticipate every possible response from 
an I/O read command, and since the responses may be 
somewhat cryptic, it is recommended that a team of ground 
controllers be assembled prior to utilizing I/O statements, to 
thoroughly discuss expected responses and potential 
consequences associated with a specific I/O read command. 
The protocol syntax for the response to the command io read 


<Port> is as follows: 
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Flag Address Control PID Info Field CRC 
OLITIII0 1 12/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits 


AX.25 Information Frame 


Flag 
OTTEVELO 








Command (1 Byte) Port (2 Bytes) Data (1 Byte) 
io_read <Port> <Data> 


AX.25 Information Field 


Where <Data> is the | byte data value to be read from the specified <Port>. The hex 


range of allowable <Data> values is 0-FF. 
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DIRECT LOW-LEVEL OPERATIONS 


Operation: Perform I/O port write 
Command: io_write <Port> <Data> 
Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
O1LETIIO 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits OLITITEO 


AX.25 Information Frame 


Command (1 Byte) Password Port (1 Byte) Data (1 Byte) 
io_write (4 Bytes) <Port> <Data> 


AX.25 Information Field 


Required Parameters: <Port> The CPU I/O port to be written to. Hex range of 
allowable values is 0-FFFF. A complete listing of I/O ports 


and their values can be found in Appendix B. 


<Data> The 8 bit data value to be written to the port specified 


using <Port>. Hex range of allowable values are 0-FF. 


Optional Parameters: None 


Function: 


Super User: 


Expected Response: 


The io_write command is used to directly write to the I/O ports 
of the microprocessor. These ports must be controlled in order 
to communicate with various PANSAT peripheral devices such 
as the programmable peripheral interface (PPI) and serial 
communications controller (SCC). Under normal operating 
conditions, I/O statements are embedded within the PANSAT 
Command Language (PCL) and are thus transparent to the 
ground controllers. I/O statements can be quite complicated, 
even to perform the simplest of tasks and this method of 
embedding the I/O statements simplifies PANSAT 


commanding and reduces the probability of errors. 


Yes 


Care should be taken when issuing I/O write statements. 
PANSAT will not directly confirm or verify individual I/O 
write commands, including mission critical commands. since it 
is difficult to anticipate very possible response from an I/O 
write command and since the response may be somewhat 
cryptic, it is recommended that a team of ground controllers be 
assembled prior to utilizing I/O write statements, to thoroughly 
discuss expected responses and potential consequences 


associated with specific I/O write commands. 
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Operation: 


Command: 


Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
OLLIIIIO 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1TTI110 


Required Parameters: 


Optional Parameters: 


Function: 


Super User: 


Expected response: 





TIME-TAGGED COMMANDING 


List the contents of the command buffer 


list_command_ buffer 


AX.25 Information Frame 


Command (1 Byte) 
list_command_buffer 
AX.25 Information Field 
None 


None 


The command list_command_buffer is used to display the 


contents of the command buffer. 


PANSAT will not directly confirm or verify the command 


list_ command_buffer. Receipt of the command buffer should 
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serve as the indication that the command was executed 
properly. If there 1s doubt whether or not the command was 
executed, the ground controller should analyze the event log for 
the appropriate indications. The protocol syntax for the 


response to the command list_command_buffer is as follows: 


Flag Address Control PID Info Field CRC Flag 
01111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1I11110 


AX.25 Information Frame 








Length (2 Bytes) Command Buffer Contents .... 
<Count> (XXX Bytes) 


AX.25 Information Field 





Command (I Byte) 
list_command_buffer 
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TASK CONTROL 


Operation: List the software tasks currently on board PANSAT. 
Command: list_tasks 
Protocol Syntax: 


Flag Address Control Info Field CRC 
O1121110 112/560 Bits 8 Bits 1028 Bytes 16 Bits 


AX.25 Information Frame 





Flag 
OLEIITLO 





Command (1 Byte) 
list_tasks 


AX.25 Information Field 

Required Parameters: None 

Optional Parameters: None 

Function: list_tasks is used to list all of the software tasks 
currently in the PANSAT task queue. Software tasks 
are executable programs that are written and compiled 
on the ground and instruct PANSAT how to perform 
under various circumstances. 

Super User: No 
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Expected Response: PANSAT will not directly confirm or verify the command 
list_tasks. Receipt of the task list should serve as the 
indication that the command was executed properly. Ground 
controllers may also examine the event log in order to confirm 
that the command was executed. There may be a maximum of 
30 tasks in the PANSAT task queue. Once the task queue is 
received from PANSAT, ground controllers will be presented 
with a graphical display showing the contents of the task 
queue and the status of each individual task. The protocol 
syntax for the response to the command list_tasks is as 


follows: 





Flag Address Control PID Info Field CRC Flag 
O1111110 112/560 Bits 8 Bits 8 Bits 1028 Bytes 16 Bits 01111110 


AX.25 Information Frame 





Command (1 Byte) Task List Length List of Task Names ... 
list_tasks (1 Byte) (X Bytes) 


AX.25 Information Field 
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USER CONTROL 


Operation: Lockout new users. 
Command: _lockout_users 
Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
OFILIIIO 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits OITIIIIO 


AX.25 Information Frame 





Command (1 Byte) Password 
lockout_users (4 Bytes) 


AX.25 Information Field 


Required Parameters: None 
Optional Parameters: None 
Function: lockout_users restricts users from logging onto PANSAT. 


This command will most likely be used in conjunction with the 
drop_users command to enable the NPS ground station to 
have exclusive access to PANSAT for purposes of uploading 
software or troubleshooting. lockout_users may also be time 


tagged and used in conjunction with the unlock _users 
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command in order to restrict the number of users during eclipse 
and hence reduce power consumption, or to prepare PANSAT 
for an impending communications session with the NPS 


ground station. 


Super User: Yes 


Expected Response: PANSAT will not directly confirm or verify the command 
lockout_users and unless there are indications to the contrary, 
it should be assumed that the command was executed properly. 
If there 1s doubt whether or not the command was executed, the 
ground controllers should analyze the event log for the 


appropriate indications. 
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DIRECT LOW-LEVEL OPERATIONS 


Operation: Perform a peripheral control bus (PCB) read 
Command: pebr <Address> 
Protocol Syntax: 


Flag Address Control PID Info Field CRC 
O1111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits 


AX.25 Information Frame 





Flag 
OLLITITO 





Command (1 Byte) Address (1 Byte) 
pebr <Address> 


AX.25 Information Field 


Required Parameters: <Address> The required <Address> parameter is one byte in 
length and specifies the PCB address and sub-address to be 
read. The four most significant bits of the address byte 
specifies the peripheral device to be read, while the two least 
significant bits specify the sub-address of the selected 
peripheral device. A complete listing of addresses and sub- 
addresses for the peripheral devices can be found in Appendix 


C 
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Optional Parameters: None 


An example of the address field for use with the pebr <Address> command. The four 
most significant bits (s3-s0) specify the address of the peripheral device to be read, while 
the least two significant bits (al-a0) specify the sub-address of the selected peripheral 


device. Bit positions three and four are not used. 


fs [eTa[@[x[x [a [oo 


pebr Address Field 


Function: Peripheral control bus (PCB) read/write statements are the 
lowest, most basic level of the PANSAT command language 
(PCL). Every command in the PCL is made up of a series of 
PCB read/write statement bundled together to form a single 
macro-type command. Thus, instead of having to issue several 
PCB read/write commands to perform a specific task, a single 
command is issued that incorporates all of the required PCB 
read/write commands for that specific task. This macro-type 
commanding simplifies PANSAT telemetry tracking and 
commanding (TT&C) and greatly reduces the probability of 
user error. It is anticipated that PCB read and write commands 
will be used only occasionally, or during troubleshooting, thus 
simplifying the effort by essentially bypassing the PCL and 


communicating directly with the peripheral devices. 
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Super User: No 


Expected Response: Care should be taken when issuing PCB read commands. 
PANSAT will not directly confirm or verify individual PCB 
read commands. Receipt of the requested information should 
serve as the indication that the command was executed 
properly. Since it is difficult to anticipate every possible 
response from a PCB read command and since the responses 
may be somewhat cryptic, it is recommended that a team of 
ground controllers be assembled prior to utilizing PCB 
statements, to thoroughly discuss expected responses and 
potential consequences associated with a specific PCB read 
statement. The protocol syntax for the response to the 


command pebr <Address> is as follows: 





Flag Address Control PID Info Field CRC Flag 
OlI1I110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1I11ITO 


AX.25 Information Frame 





Command (1 Byte) Address (2 Bytes) Data (1 Byte) 
pebr <Address> <Data> 


AX.25 Information Field 


Where <Data> is the 1 byte data value to be read from the specified <Address>. The 


hex range of allowable <Data> values is 0-FF. 
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DIRECT LOW-LEVEL OPERATIONS 


Operation: Perform a peripheral control bus (PCB) write 
Command: pcebw <Address> <Data> 


Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
O1IT1110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1111110 


AX.25 Information frame 


Command (1 Byte) Password Address (1 Byte) Data (1 Byte) 
pebw (4 Bytes) <Address> <Data> 


AX.25 Information field 


Required Parameters: <Address> The required <Address> parameter is one byte in 
length. The four most significant bits specify the addresses of 
the various peripheral devices, while the four least significant 
bits specify the sub-addresses of the selected peripheral device. 
A complete listing of addresses and sub-addresses for the 


peripheral devices can be found in Appendix C. 


Optional Parameters: None 





Example: 





a [eT [olx [qa [or 


Function: 


Super User: 


Expected Response: 


Address Field 


Peripheral control bus (PCB) read/write statements are the 
lowest, most basic level of the PANSAT command language 
(PCL). Every command in the PCL is made up of a series of 
PCB read/write statements bundled together to form a single 
macro-type command. Thus, instead of having to issue several 
PCB read/write commands to perform a specific task, a single 
command is issued that incorporates all of the required PCB 
read/write commands for that specific task. This macro-type 
commanding simplifies PANSAT TT&C and greatly reduces 
the probability of user error. It is anticipated that PCB read and 
write commands will be used only occasionally, or during 
troubleshooting, thus simplifying the effort by essentially 
bypassing the PCL and communicating directly with the 


peripheral devices. 


Yes 


Care should be taken when issuing PCB write commands. 


PANSAT will not directly confirm or verify individual PCB 
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write commands, including mission critical commands. Since 
it is difficult to anticipate every possible response from a PCB 
write command and since the response may be somewhat 
cryptic, it is recommended that a team of ground controllers be 
assembled prior to utilizing PCB statements, to thoroughly 
discuss expected responses and potential consequence 


associated with a specific PCB write statement. 
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TIME-TAGGED COMMANDING 


Operation: Purge the entire PANSAT command buffer 
Command: purge command_buffer 
Protocol Syntax: 


Flag Address Control PID Info Field CRC 
OITIT110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits 


AX.25 Information Frame 





Flag 
O1ltI1IO 





Command (1 Byte) Password 
purge_command_buffer (4 Bytes) 


AX.25 Information Field 


Required Parameters: None 
Optional Parameters: None 
Function: purge_command_buffer is used to purge the current contents 


of the command buffer. 


Super User: Yes 
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Expected response: 


purge command buffer is considered a mission 
critical command and in addition to requiring a valid 
password, PANSAT will query the NPS ground 
station prior to execution in order to verify its 
intentions. The NPS ground station will be 
immediately notified that the command buffer has 
been purged and an entry will be made to the event 
log. If PANSAT moves over the horizon without 
being able to notify the NPS ground station that the 
command buffer has been purged, PANSAT will not 
attempt to inform the NPS ground station of this event 
on subsequent communications sessions. At this 
point, the only indications that the ground controllers 
will have that the command buffer was purged will be 


in the event log. 
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EVENT LOG 


Operation: Purge the current event log. 
Command: purge event log 


Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
O1E11110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1LI1110 


AX.25 Information Frame 


Command (I Byte) Password 
purge_event_log (4 Bytes) 


AX.25 Information Field 
Required Parameters: None 
Optional Parameters: None 
Function: purge event log instructs PANSAT to delete the contents of 


the event log. The event log may be purged at any time, 


regardless of whether or not 1t has been downlinked. 


Super User: Yes 
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Expected Response: 





purge_event_log is considered a mission critical command and 
in addition to requiring a valid password, PANSAT will query 
the NPS ground station prior to execution 1n order to verify its 
intentions. The NPS ground station will be immediately 
notified that the log has been purged and an entry will be made 
to the new event log, which will be automatically created upon 
deletion of the old event log. If PANSAT moves over the 
horizon without being able to notify the NPS ground station 
that the event log has been purged, PANSAT will not attempt 
to inform the NPS ground station of this event on subsequen: 
communications sessions. At this point, the only indication 
that the ground controllers will have that the event log was 
purged will be the new event log. The event log may be 
purged at any time, even if it has not been downlinked to the 
NPS ground station. The event log will be purged and a new 
log started automatically upon the completion of a successful 


downlink. 
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TELEMETRY CONTROL 


Operation: Purge the telemetry data stored in the flash memory. 
Command: purge flash_telem 
Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
O1111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits 01111110 


AX.25 Information Frame 





Command (1 Byte) Password 
purge_flash_telem (4 Bytes) 


AX.25 Information Field 


Required Parameters: None 
Optional Parameters: None 
Function: purge flash_telem commands PANSAT to purge all of the 


telemetry data stored in the flash memory. Flash telemetry 
may be purged at any time, regardless of whether or not the 


telemetry has been downlinked. 


Super User: Yes 
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Expected Response: 





purge flash telem is considered a mission critical command 
and in addition to requiring a valid password, PANSAT will 
query the NPS ground station prior to execution in order to 
verify its intentions. The NPS ground station will be 
immediately notified that the flash memory has been purged 
and an entry will be made to the event log. If PANSAT moves 
over the horizon without being able to notify the NPS ground 
station that the flash memory was purged, PANSAT will not 
attempt to inform the NPS ground station of this event on 
subsequent communications session. At this point, the only 
indications that the ground controller will have that the flash 


memory has been purged will be in the event log. 
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Operation: 


Command: 


Protocol Syntax: 





Required Parameters: 


Optional Parameters: 


Function: 


Super User: 





TELEMETRY CONTROL 


Purge the telemetry data stored in static RAM. 


purge sram_telem 


Flag Address Control PID Info Field CRC Flag 
O1111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits OFEIIIO 


AX.25 Information Frame 


Command (1 Byte) Password 
purge_sram_telem (4 Bytes) 


AX.25 Information field 


None 
None 


purge sram_telem commands PANSAT to purge all of the 
telemetry data stored in the static RAM. SRAM telemetry may 
be purged at any time regardless of whether or not the 


telemetry has been downlinked. 


Yes 
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Expected Response: 





purge sram_telem is considered a mission critical command 
and in addition to requiring a valid password, PANSAT will 
query the NPS ground station prior to execution in order to 
verify its intentions. The NPS ground station will be 
immediately notified that the stored telemetry has been purged 
and an entry will be made to the event log. If PANSAT moves 
over the horizon without being able to notify the NPS ground 
station that the telemetry has been purged, PANSAT will not 
attempt to inform the NPS ground station of this event on 
subsequent communications sessions. At this point, the only 
indication that the ground controllers will have that the stored 


telemetry has been purged will be in the event log. 
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FILE SYSTEM CONTROL 


Operation: Upload a file to PANSAT 
Command: put_file <Drive:\Path\Filename> 


Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
O1111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1111110 


AX.25 Information Frame 


Command (1 Byte) DOS File Path & Filename File Length File Data 
put_file <Filename> (4 Bytes) (XXX Bytes) 


AX. 25 Information Field 


Required Parameters: <Filename> The DOS path & filename to send to PANSAT. 
This is the path & filename as it exists on the ground station 
file system, NOT how it will appear on the PANSAT file 
system. This format allows ground controllers to retrieve and 
send files from any of the various sub-directories of the ground 
station hard drive thus keeping the ground station better 


organized. 








Optional Parameters: None 


Function: The command put_<Filename> is use to send or upload 


a specified file to PANSAT. 


Super User: No 


Expected Response: PANSAT will not directly confirm or verify the command 
put_<Filename> and unless there are indications to the 
contrary, it should be assumed that the command was executed 
properly. If there is doubt as to whether or not the command 
was executed, ground controllers should examine the file 


directory and the event log for the appropriate indications. 
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OS CONTROL 


Operation: Read real-time clock 
Command: read clock 
Protocol Syntax: 


Flag Address Control PID Info Field 
O1111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 


AX.25 Information Frame 





CRC Flag 
16 Bits O1111110 





Command (1 Byte) 
read_clock 


AX.25 Information Field 


Required parameters: None 

Optional Parameters: None 

Function: read_clock is used to read the clock on board PANSAT. 
Super User: No 
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Expected Response: PANSAT will not directly confirm or verify the command 
read _ clock. Receipt of the time information (in Universal 
Time Code format: yy/mm/dd/hh/mm/ss) should serve as the 
indication that the command was executed properly. If there is 
doubt as to whether or not the command was executed, ground 
controllers should examine the event log. The protocol syntax 


for the response to the command read_clock is as follows: 





Flag Address Control PID Info Field CRC Flag 
01111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits OFIIIIEO 


AX.25 Information Frame 





Command (1 Byte) UTC (4 Bytes) 
read_clock <UTC> 


AX.25 Information Field 
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EVENT LOG 


Operation: Read the current event log. 


Command: read_event_log 


Protocol Syntax: 





AX.25 Information Frame 


Command (1 Byte) 
read_event_log 


AX.25 Information Field 


Required Parameters: None 
Optional Parameters: None 
Function: read_event_log commands PANSAT to transmit the contents 


of the event log. 


Super User: No 
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Expected Response: PANSAT will not directly confirm or verify the command 
read event log. Receipt of the event log should serve as the 
indication that the command was executed properly. PANSAT 
will first transmit the contents of the log and then make an 
entry that the command was executed. Hence, the transmitted 
event log will not show the most recent read_event_log 
command. If there is doubt as to whether or not the command 
was executed, ground controllers should examine subsequent 
logs. The protocol syntax for the response to the command 


read _ event log is as follows: 


Flag Address Control PID Info Field CRC Flag 
01111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits OLIITIIO 


AX.25 Information Frame 


Command (1 Byte) Event Log 
read_event_log (XYZ Bytes) 


AX.25 Information Field 
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TELEMETRY CONTROL 


Operation: Read the telemetry data stored in the flash memory. 
Command: read_flash_telem 


Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
O1111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1111110 


AX.25 Information Frame 





Command (1 Byte) 
read_flash_telem 


AX.25 Information Field 


Required Parameters: None 
Optional Parameters: None 
Function: read _ flash_telem commands PANSAT to transmit the 


telemetry data stored in the flash memory. 


Super User: No 
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Expected Response: PANSAT will not directly confirm or verify the command 
read flash _telem. Receipt of the flash data should serve as 
the indication that the command was executed properly. If 
there is doubt as to whether or not the command was executed, 
ground controllers should examine the event log. The protocol 
syntax for the response to the command read_flash_telem 1s as 


follows: 


Flag Address Control PID info Field CRC Flag 
O1111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1J11110 


AX.25 Information Frame 








Command (1 Byte) Length (4 Bytes) Fiash Telemetry Data ... 
read _flash_telem <Count> (XXX Bytes) 


AX.25 Information Field 
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MASS STORAGE UNIT 


Operation: Read data from a specified flash memory location. 
Command: read flash_mem <Address> 


Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
OF111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O11TF1TIO 


AX.25 Information Frame 





Command (1 Byte) Address (3 Bytes) 
read_flash_mem <Address> 


AX.25 Information Field 


Required Parameters: <Address> Specifies the flash memory location to begin 
reading data. nx 16 bytes of data will be read, where n 
defaults to 1 and may be changed to any value between I - 15 
by changing the operating system Saramieiers: A maximum of 
15 x 16 bytes, or 240 bytes of information may be read with 


this command. 


Optional Parameters: None 
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Function: 


Super User: 


Expected Response: 


Flag 
O1111110 








The read_flash_mem command is used to read a specific flash 
memory location or a specific range of flash memory locations 
which may be beneficial to ground controllers performing 


troubleshooting. 


No 


PANSAT will not directly confirm or verify the command 
read flash mem. Receipt of the flash memory contents 
should serve as the indication that the command was executed 
properly. If there is doubt as to whether or not the command 
was executed, ground controllers should examine the event log 
for the appropriate indications. The protocol syntax for the 


response to the command read_flash_mem is as follows: 


Address Control PID Info Field CRC Flag 
112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1111110 


AX.25 Information Frame 


Command (1 Byte) Address (3 Bytes) Flash Memory Contents ... 
read_flash_mem <Address> (240 Bytes Max.) 


AX.25 Information Field 
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OS CONTROL 


Operation: Read the Operating System parameters 
Command: read os param 
Protoco} Syntax: 


Flag Address Control PID Info Field CRC Flag 
OT1IEI10 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits OTTTEIIO 


AX.25 Information Frame 





Command (1 Byte) 
read_os param 


AX.25 Information Field 
Required Parameters: None 
Optional! Parameters: None 
Function: The read_os_param command is used to read the current 


parameters of the operating system. Operating system 
parameters (which are still to be determined) include the 
version of the current operating system, time and date, and task 


list. 


Super User: No 
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Expected response: PANSAT will not directly confirm or verify the command 
read_os_ param. Receipt of the parameters should serve as the 
indication that the command was executed properly. If there is 
doubt as to whether or not the command was executed, ground 
controllers should examine the event log. The protocol syntax 


for the response to the command read_os_param is as follows: 


Flag Address Control PID Info Field CRC Flag 
OFLITTIO 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1ITII10 


AX.25 Information Frame 


Command (1 Byte) OS Parameter list 
read_os_param (2 Bytes) 


AX.25 Information Field 
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Operation: 


Command: 


Protocol Syntax: 





Required Parameters: 


Optional Parameters: 


Function: 


Super User: 





TELEMETRY CONTROL 


Read the most recent telemetry 


read_recent_telem 


Flag Address Control PID Info Field CRC 
O1VIE110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits 


AX.25 Information Frame 


Command (1 Byte) 
read_recent_telem 
AX.25 Information Field 
None 


None 


read_recent_telem commands PANSAT to transmit the 


current, most recent telemetry data. 


No 
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Flag 
01111110 








Expected Response: PANSAT will not directly confirm or verify the command 
read _recent_telem. Receipt of the most recent telemetry data 
should serve as the indication that the command was executed 
properly. If there is doubt as to whether or not the command 
was executed, ground controllers should examine the event log. 
The protocol syntax for the response to the command 


read_recent_telem is as follows: 


Flag Address Control PID Info Field CRC Flag 
01111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits OLIII1T0 


AX.25 Information Frame 


Command (1 Byte) Length Telemetry Data ... 
read_recent_telem (2 Bytes) (X Bytes) 


AX.25 Information Field 
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MASS STORAGE UNIT 


Operation: Read data from a specified static RAM location. 
Command: read_sram_mem <Address> 
Protocol Syntax: 


Flag Address Control PID info Field CRC Flag 
OL111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits OHTTTIIO 


AX.25 Information Frame 


Command (1 Byte) Address (3 Bytes) 
read_sram_mem <Address> 


AX.25 Information Field 


Required Parameters: <Address> Specifies the SRAM address to begin reading data. 
n x 16 bytes of data will be read, where n defaults to 1 and may 
be changed to any value between 1 - 15 by changing the 
operating system parameters. A maximum of 15 x 16 bytes, or 


240 bytes of information may be read with this command. 


Optional Parameters: None 
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Function: 


Super User: 


Expected Response: 





Flag Address Control PID 
O1111110 112/560 Bits 8 Bits 8 Bits 


The read_sram_mem command is used to read a specific 
SRAM location or a specific range of SRAM locations which 
may be beneficial to ground controllers performing 


troubleshooting. 


PANSAT will not directly confirm or verify the command 

read sram_mem. Receipt of the SRAM contents should serve 
as the indication that the command was executed properly. If 
there is doubt as to whether or not the command was executed, 
ground controllers should examine the event log for the 
appropriate indications. The protocol syntax for the response 


to the command read_sram_mem is as follows: 


Info Field CRC Flag 
256 Bytes 16 Bits O11TT1I0 


AX.25 Information Frame 





Command {1 Byte) Address (3 Bytes) SRAM Memory Contents ... 
read_sram_mem <Address> (240 Bytes Max.) 


AX.25 Information Field 
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TELEMETRY CONTROL 


Operation: Read the telemetry data stored in the static RAM. 
Command: read_sram_telem 


Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
01111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1111110 


AX.25 Information Frame 


Command (1 Byte) 
read_sram_telem 


AX.25 Information Field 


Required Parameters: None 
Optional Parameters: None 
Function: read_sram_telem commands PANSAT to transmit the 


telemetry data stored in the static RAM. 


Super User: No 
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Expected Response: PANSAT will not directly confirm or verify the command 
read sram_telem. Receipt of the stored telemetry data should 
serve as the indication that the command was executed 
properly. If there is doubt as to whether or not the command 
was executed, ground controllers should examine the event log. 
The protocol syntax for the response to the command 


read_sram_telem is as follows: 


Flag Address Control PID Info Field CRC Flag 
01111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits 01141110 


AX.25 Information Frame 





Command (1 Byte) Length (4 Bytes) Telemetry Data File Contents... 
read sram_telem <Length> (X Byte) 


AX.25 Information Field 
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ELECTRICAL POWER SUBSYSTEM 


Operation: Reset watchdog timer 
Command: reset_watchdog 
Protocol Syntax: 


Flag Address Control PID info Field CRC Flag 
O1I11110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1111110 


AX.25 Information frame 





Command (1 Byte) 
reset_watchdog 


AX.25 Information Field 
Required Parameters: None 
Optional Parameters: None 
Function: reset_watchdog 1s used to reset the watchdog timer on board 


PANSAT. Every 8 minutes, the selected DCS signals the 
watchdog timer that it is still functioning. If the selected DCS 
fails to signal the watchdog timer in the allotted time, the 
watchdog timer assumes that there is a problem with that 
particular DCS and switches to the alternate DCS. By issuing 


the reset_watchdog command, ground controllers are assured 
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Super User: 


Expected Response: 





that they will be working with the same DCS for at least 8 
minutes and thus simplifying any potential troubleshooting 


scenarios. 


PANSAT will not directly confirm or verify the command 
reset_watchog. If there is doubt as to whether or not the 
command was executed, ground controller should examine the 


event log. 


108 


a a a yet 








COMMUNICATIONS UNIT 


Operation: Select Transceiver parameters 
Command: sel trans param <Control Byte> 


Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
01111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits 01111110 


AX.25 Information Frame 





Command (1 Byte) Password Control Byte (1 Byte) 
sel_trans_param (4 Bytes) <Contro! Byte> 


AX.25 Information Field 





Required Parameters: 


Not Not Mixer Mixer LNA LNA HPA HPA 
used used Bit !# Bit #2 Bit #1 Bit #2 Bit #1 Bit #2 


Control Byte 





Bit combination 00 is not valid 
Bit combination 11 is not valid 
Bit combination 01 selects device #1 


Bit combination 10 selects device #2 


109 





Optional Parameters: 


Function: 


Example: 





None 


sel trans_param is used to set the transceiver parameters. 
Each transceiver parameter (mixer, LNA, HPA) is controlled 
using two bits of the control byte. The two least significant bit 
positions are used to select the HPA. The next most significant 
bits (positions 3 & 4) are used to select the LNA and the next 
two significant bits (positions 5 & 6) are used to select the 
mixer. The two most significant bits (position 7 & 8) are not 
used in this command, are not read by the microprocessor, and 
set permanently to 0 for completeness. The example below 
shows mixer 1#, LNA 1#, and HPA 1# selected and is also the 


default control byte pattern. 


Not Not 1 
used used 


Super User: 


Expected Response: 


Yes 


sel trans_param is considered a mission critical command 


and in addition to requiring a valid password, PANSAT will 
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query the NPS ground station prior to execution in order to 
verify its intentions. The NPS ground station will be 
immediately notified that the state of the transceiver has been 
changed and an entry will be made to the event log. If 
PANSAT moves over the horizon without being able to notify 
the NPS ground station that the state of the transceiver has 
changed, PANSAT will not attempt to inform the NPS ground 
station of this event on subsequent communications sessions. 
At this point, the only indications that the ground controllers 
will have that the state of the transceiver has changed will be 


through the event log. 
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COMMUNICATIONS UNIT 


Operation: Select Transmit Mode 
Command: select_xmit_ mode <Mode> 
Protocol Syntax: 


Flag Address Control PID Info Feld CRC Flag 
01111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1EI1110 


AX.25 Information Frame 





Command (I Byte) Password Xmit Mode (1 Byte) 
select_xmit_mode (4 Bytes) <Mode> 


AX.25 Information Field 


Required Parameters: <Mode> BPSK = 00 
Spread Spectrum = FF 


Optional Parameters: None 
Function: The command select_xmit_mode is used to set the 
transmission mode of PANSAT to either BPSK or spread 


spectrum. 


Super user: Yes 
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Expected Response: PANSAT will not directly confirm or verify the command 
select_mode. If there is doubt as to whether or not the 
command was executed, ground controllers should examine the 


event log for the appropriate indications. 
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OS CONTROL 


Operation: Set the real-time clock on board PANSAT 
Command: set_clock <UTC> 


Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
OLLLETIO 112/560 Bits 8 Bits 8 Bits 1028 Bytes 16 Bits O1LITI1O 


AX.25 Information Frame 


Command (1 Byte) Password UTC (4 Bytes) 
set_clock (1 Byte) <UTC> 


AX.25 Information Field 


Required parameters: <UTC> In YY/MM/DD/HH/MM/ISS format. 


Optional Parameters: None 


Function: set_clock is used to update or reset the clock on board 
PANSAT. Ground controllers should enter the current UTC 
time for the required parameter <UTC>. The ground station 
software will then calculate the required processing and 
transmission time and adjust the input UTC accordingly, thus 


resulting in a more accurate clock on board PANSAT. 
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Super User: Yes 


Expected Response: PANSAT will not directly confirm or verify the command 
set_clock. If there is doubt as to whether or not the command 


was executed, ground controllers should examine the event log. 
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TELEMETRY CONTROL 


Operation: Set the telemetry polling rates 
Command: set polling rates <Table #> 
Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
O1111T10 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1111110 


AX.25 Information Frame 





Command (1 Byte) Password Table data 
set_polling_rates (4 Bytes) (??? Bytes) 


AX.25 Information Field 


Required Parameters: <Table #> See the PANSAT Software Detailed Design 


Document for a description of the <Table #> parameter format. 


Optional Parameters: None 


Function: set polling rates instructs PANSAT how often to sample the 
various telemetry points. The command set_polling_ rates 
requires the ground controllers to specify a table number 
<Table #> to be used with the command. A table ts essentially 
a matrix that lists all of the telemetry points and how often they 


are to be polled or sampled. Many tables will be constructed, 
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Super User: 


Expected Response: 





numbered and available for selection by the ground controllers 
depending on the current operational scenario. It should be 
understood that in order to change the polling rate of one 
specific telemetry point, either an existing table number must 
be edited or a new table number constructed since the entire 
table is what 1s transmitted and not just one entry within a 


specific table. 


Yes 


PANSAT will not directly confirm or verify the command 


set polling rates. If there is doubt as to whether or not the 


command was executed, ground controllers should examine the 


event log. 
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COMMUNICATIONS UNIT 


Operation: Select Power Level 
Command: set_power_ level <Level> 
Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
O1TI1110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1111110 


AX.25 Information Frame 





Command (I Byte) Password Power level (I Byte) 
set_power_level (4 Bytes) <Level> 


AX.25 Information Field 


Required Parameters: <Level> One of four discrete values, that are still to be 


determined, may be selected. 


Optional Parameters: None 


Function: The command set_power_level is used to set the transmitter 


power level on board PANSAT. 


Super User: Yes 
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Expected Response: PANSAT will not directly confirm or verify the command 
set_power_level. if there is doubt as to whether or not the 
command was executed properly, ground controllers should 


examine the event log for the appropriate indications. 
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ELECTRICAL POWER SUBSYSTEM 


Operation: Set power switches 


Command: set_pwr_switch <Control Byte> 


Protocol Syntax: 


Flag Address Control PID info Field CRC Flag 
01111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits OITIEETIO 


AX.25 Information Frame 





Command (1 Byte) Password Control Byte (1 Byte) 
set _pwr_switch (4 Bytes) <Control Byte> 


AX.25 Information Field 


Required Parameters: At least one optional parameter 


Optional Parameters: 





Not Not Not TMUX TMUX 
MSB MSA 
Used Used Used B A 


Control Byte 
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Function: 


Super User: 


Expected Response: 


<rf=1/0> Toggle on/off RF system 

<msa = 1/0> Toggle on/off mass storage A 
<msb = 1/0> Toggle on/off mass storage B 
<amuxa = 1/0> Toggle on/off analog mux A 


<amuxb = 1/0> Toggle on/off analog mux B 


set_pwr_switch is used to toggle on/off the power switches to 
the five peripheral devices. Each bit position within the control 
byte corresponds to a specific peripheral device and by 
toggling these bits either on or off, ground controllers are able 
to control power to the peripheral devices. Toggling power to 
multiple peripheral devices may be achieved with a single 


set_pwr_switch command. 


Yes 


set_pwr_switch 1s considered a mission critical command and 
in addition to requiring a valid password, PANSAT will query 
the NPS ground station prior to execution in order to verify its 
intentions. The NPS ground station will be immediately 
notified that the state of a power switch has been changed and 
an entry will be made in the event log. If PANSAT moves 
over the horizon without being able to notify the NPS ground 
station that the state of a power switch has changed , PANSAT 
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will not attempt to inform the NPS ground station of this event 
on subsequent communications sessions. At this point, the 
only indications that the ground controllers will have that the 


state of a power switch has changed will be in the event log. 
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TELEMETRY CONTROL 


Operation: Set the telemetry storage rates 
Command: set storage rates <Table #> 


Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
O1111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1T11110 


AX.25 Information Frame 





Command (1 Byte) Password Table Data 
set_storage_rates (4 Bytes) (7?? Bytes) 


AX.25 Information Field 


Required Parameters: <Table #> See the PANSAT Software Detailed Design 


Document for a description of the <Table #> parameter format. 
Optional Parameters: None 


Function: set_storage_rates instructs PANSAT how often to store the 
various telemetry points. The command set_storage rates_ 
rates requires the ground controllers to specify a table number 
<Table #> to be used with the command. A table is essentially 


a matrix that lists all of the telemetry points and how often 
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Super User: 


Expected Response: 


samples should be stored. Many tables will be constructed, 
numbered, and available for selection by the ground controllers 
depending on the current operational scenario. It should be 
understood that in order to change the storage rate of one 
specific telemetry point either an existing table number must be 


edited or a new table number constructed. 


Yes 


PANSAT will not directly confirm or verify the command 
set storage rates. If there is doubt as to whether or not the 
command was executed, ground controllers should examine the 


event log. 
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TASK CONTROL 


Operation: Start a software tasks on board PANSAT. 
Command: start_task <Task Name> 


Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
OLII111O 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits 01111110 


AX.25 Information Frame 


Command (1 Byte) Password Task Name 
start_task (4 Bytes) <Task Name> 


AX.25 Information Field 


Required Parameters: <Task Name> The name of the software task to be started and 
may be up to eight characters in length. All software tasks will 


have the same three-character extension. 


Optional Parameters: None 


Function: start_task is used to start a software task in the PANSAT task 
queue. Software tasks are executable programs that are written 
and compiled on the ground and instruct PANSAT how to 


perform under various circumstances. 
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Super User: Yes 


Expected Response: start_task <Task Name> is considered a mission critical 
command and in addition to requiring a valid pass word, 
PANSAT will query the NPS ground station prior to execution 
in order to verify its intentions. The NPS ground station will 
be immediately notified that a software task has been started 
and an entry will be made to the event log. If PANSAT moves 
over the horizon without being able to notify the NPS ground 
station that a software task was started, PANSAT will not 
attempt to inform the NPS ground station of this event on 
subsequent communications sessions. At this point, if there is 
doubt whether or not a task was started, ground controllers 
should execute a list_tasks command to verify the contents of 
the task queue and the status of the task that was to have been 
started. Ground controllers may also examine the event log in 


order to confirm that the command was executed. 
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Operation: 


Command: 


Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
OFEEI1IO 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1NI1110 


TASK CONTROL 


Stop a software tasks on board PANSAT. 


stop_task <Task Name> 


AX.25 Information Frame 


Command (1 Byte) Password Task Name 
Stop_task (4 Bytes) <Task Name> 


Required Parameters: 


Optional Parameters: 


Function: 


AX.25 Information field 


<Task Name> The name of the software task to be stopped 
and may be up to eight characters in length. All software tasks 


will have the same three-character extension. 


None 


stop_task 1s used to stop a software task in the PANSAT task 
queue. Software tasks are executable programs that are written 
and compiled on the ground and instruct PANSAT how to 


perform under various circumstances. 
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Super User: 


Expected Response: 


stop task <Task Name> is considered a mission critical 
command and in addition to requiring a valid password, 
PANSAT will query the NPS ground station prior to execution 
in order to verify its intentions. The NPS ground station will 
be immediately notified that a software task has been stopped 
and an entry will be made to the event log. If PANSAT moves 
over the horizon without being able to notify the NPS ground 
station that a software task was stopped, PANSAT will not 
attempt to inform the NPS ground station of this event on 
subsequent communications sessions. At this point, the only 
indications that a software task has been stopped will be in the 
event log, or by ground controllers issuing a list_tasks 
command to verify the contents of the task queue and the status 


of the task that was to have been stopped. 
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OS CONTROL 


Operation: Stop watchdog timer updates. 
Command: stop _wdog 
Protocol] Syntax: 


Flag Address Control PID Info Field CRC Flag 
O11ET1IO 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits O1l11110 


AX.25 Information Frame 





Command (1 Byte) Password 
stop_wdog (4 Bytes) 


AX.25 Information Field 


Required Parameters: None 
Optional Parameters: None 
Function: The stop _wdog command instructs the current system 


controller to stop sending updates to the watchdog timer. 


Super User: Yes 
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Expected response: 





PANSAT will not directly confirm or verify the command 
stop_wdog. If successful however, after 4/8 minutes, the 
watchdog timer will time out, thus resulting in the alternate 
system controller being booted up and brought on line. If there 
is doubt as to whether or not the command was executed, 


ground controllers should examine the event log. 
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USER CONTROL 


Operation: Allow new users. 
Command: unlock_users 
Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
OL11IEIO 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits OWIT1I0 


AX.25 Information Frame 





Command (1 Byte) Password 
unlock_users (4 Bytes) 


AX.25 Information Field 
Required Parameters: None 
Optional Parameters: None 
Function: unlock_users is used subsequent to the lockout_users 


command to restore normal user access to PANSAT. 
unlock users may be time tagged and used in conjunction 
with the lockout_user command in order to restrict the 
number of users during eclipse and hence reduce power 
consumption, or to prepare PANSAT for an impending 


communications session with the NPS ground station. 
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Super User: 


Expected Response: 





PANSAT will not directly confirm or verify the command 
unlock_users and unless there are indications to the contrary, 
it should be assumed that the command was executed properly. 
If there is doubt whether or not the command was executed, the 
ground controllers should analyze the event log for the 


appropriate indications. 
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OS CONTROL 


Operation: Update the current operating system parameters. 
Command: update_os_ param <Parameter List> 
Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
O1111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits 01111110 


AX.25 Information Frame 





Command (1 Byte) Password Parameter List... 
update os param (4 Bytes) (2 Bytes) 


AX.25 Information Field 
Required Parameters: <Parameter List> 
Optional Parameters: None 
Function: The update_os_ param command ts used to update the 


operating system parameters. It is useful when the entire 
operating system need not be updated, but only revised, or 
changed slightly. A complete list of operating system 


parameters ts still under development. 


Super User: Yes 
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Expected response: 





PANSAT will not directly confirm or verify the command 
update os param. If there 1s doubt as to whether or not the 
command was executed, ground controllers may execute a 
read _os_ param command and view the result or, examine the 


event log. 
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MASS STORAGE UNIT 


Operation: Write data to a specified flash memory location 
Command: write _flash_mem <Address> <Data> 
Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
OL11E110 112/560 Bits 8 Bits 8 Bits 256 Bytes i6 Bits OLISTIIO 


AX.25 Information Frame 





Command (1 Byte) Password Address (3 Bytes) Data (1 Byte) 
write_flash_mem (4 Bytes) <Address> <Data> 


Ax.25 Information Field 


Required Parameters: <Address> Specifies the flash storage address to 
begin witting the data. Valid range is from 0 - 
OX7FFFF. 
<Data> The data to be written to flash storage. Valid 


range is from 0 - OXFF. 


Optional Parameters: None 
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Function: 


Super User: 


Expected Response: 





The write_flash_mem command is used to write data to a 
specific flash storage location. This command may be 
beneficial to ground controllers performing troubleshooting or 


attempting to repair a file that was somehow corrupted. 


Yes 


write flash_mem is considered a mission critical command 
and in addition to requiring a valid password, PANSAT will 
query the NPS ground station prior to execution in order to 
verify its intentions. The NPS ground station will be 
immediately notified that a flash storage location has been 
overwritten and an entry will be made to the event log. If 
PANSAT moves over the horizon without being able to notify 
the NPS ground station that a specific flash storage location has 
been overwritten, PANSAT will not attempt to inform the NPS 
ground station of this event on subsequent communications 
sessions. At this point, the only indication that the ground 
controllers will have that a flash storage location has been 


overwritten will be in the event log. 
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MASS STORAGE UNIT 


Operation: Write data to a specified static RAM location 
Command: write _sram_mem <Address> <Data> 
Protocol Syntax: 


Flag Address Control PID Info Field CRC Flag 
01111110 112/560 Bits 8 Bits 8 Bits 256 Bytes 16 Bits 01111110 


AX.25 Information Frame 





Command (1 Byte) Password Address (3 Bytes) Data (1 Byte) 
write_sram_mem (4 Bytes) <Address> <Data> 


AX.25 Information Field 


Required Parameters: <Address> Specifies the sram storage address to 
begin witting the data. Valid range is from 0 - 
OX3FFFF. 
<Data> The data to be written to sram storage. Valid 


range 1s from 0 - OXFF. 


Optional Parameters: None 
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Function: 


Super User: 


t-xpected Response: 





The write_sram_mem command Is used to write data to a 
specific sram storage location. This command may be 
beneficial to ground controllers performing troubleshooting or 


attempting to repair a file that was somehow corrupted. 


Yes 


write _sram_mem is considered a mission critical command 
and in addition to requiring a valid password, PANSAT will 
query the NPS ground station prior to execution in order to 
verify its intentions. The NPS ground station will be 
immediately notified that a sram memory location has been 
overwritten and an entry will be made to the event log. If 
PANSAT moves over the horizon without being able to notify 
the NPS ground station that a specific sram storage location has 
been overwritten, PANSAT will not attempt to inform the NPS 
ground station of this event on subsequent communications 
sessions. At this point, the only indication that the ground 
controllers will have that a sram storage location has been 


overwritten will be in the event log. 
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APPENDIX B. A COMPLETE LISTING OF I/O PORTS AND THEIR 
DEFINITIONS 










The microprocessor communicates with the other devices using the allocated port 


addresses. These address lines provide for the basic control and data I/O of these devices. 
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APPENDIX C. A COMPLETE LISTING OF ADDRESSES AND 
SUBADDRESSES FOR PERIPHERAL DEVICES. 





sr Poversiaem | vom 
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